The Universal Serial Bus (USB) is a half duplex single logical wire which permits relatively high speed serial communication between a host system bus and devices on the USB. The operations of the USB are generally well known in the art. Architectural details and signaling characteristics are explicitly defined in Universal Serial Bus Specification, Version 1.0, Jan. 19, 1996. Similarly, one possible host controller interface (UHCI) is defined for the interface between the USB and a host system bus. Details in that interface are set forth in Universal Host Controller Interface Design Guide, Revision 1.1., March 1996.
The USB permits four types of transfers: isochronous transfers, interrupt transfers, control transfers, and bulk transfers. Isochronous transactions are characterized by a constant fixed data rate between the USB device and the host and USB guarantees that a required maximum data rate can be transferred in each frame. USB does not require that these transactions occur at this maximum rate in every frame. Failed transactions are not retried. Interrupt transactions are characterized by small spontaneous transfers from a device. Like isochronous transactions, interrupt transactions have a guaranteed maximum data rate, but interrupt transactions are retired after limited retries due to data corruption or other errors. Control transactions are used to provide a control channel from the host to the USB devices through which control, status, and configuration information may flow and always consist of a set-up stage and zero or more data stages followed by a status stage where a stage consists of one or more transactions. Bulk transactions are characterized by guaranteed transmission of data between client and host under relaxed latency requirements.
The USB transfers data in frames. Every frame is one millisecond long and begins is with a start of frame packet. The host controller schedules pending transactions with isochronous transactions scheduled first, interrupt transactions next and control and bulk transactions following in turn. In general, scheduling always presumes a worst case transmission characteristic.
The USB Host Controller is responsible for maintaining frame integrity. In particular, it should never start a Device-to-Host transaction unless there is time left in the frame to complete the transaction. Transactions allow data transfer over the USB. Some number of transactions are moved over the bus in each frame. A frame schedule is used by the host controller to determine what specific transactions are moved in what frame. Different host controllers require different organization and control of frame schedules.
In general, frame schedules are constructed using transaction descriptors (TDs). TDs are data structures containing characteristics of the transaction requested on the USB. Even though four types of transfers exist on the USB, all TDs use the same format, with different transfer types distinguished by a number of control bits. The host controller fetches a TD and generates the proper transaction on the USB.
The Universal Host Controller Interface (UHCI) specification provides a programmable frame threshold that is used to determine whether to start a transaction. In effect, once the threshold has been exceeded, UHCI will not start any transaction, regardless of its size. This threshold has two settings: thirty-two bytes or sixty-four bytes. However, the programmable frame threshold does not provide an adequate mechanism for optimal transaction scheduling, particularly for transactions exceeding sixty-four bytes.
When the Host Controller fetches TDs from memory, PCI latencies can delay delivery of the TD. PCI latencies occur because of, inter alia, ordering rules, effects of concurrent bus transactions, and the inability to precisely predict when a PCI bus transaction will be completed. A problem may be created when the transaction data size is greater than sixty-four bytes and the TD fetch is completed a relatively short time before the end of the frame (e.g. before the threshold is traversed, but after the point when the transaction should have been started). A transaction for which TD delivery (and therefore initiation of the transaction) is delayed is considered held off. The Universal Host Controller Interface will start held-off transactions if the sixty-four byte threshold has not been reached. In those cases where the held-off transaction is a Read transaction and the data length is greater than sixty-four bytes, the failure (and recovery) side-effects are significant and always observable by the user.
Accordingly, there is a need for a mechanism to avoid starting held-off transactions which cannot be completed without violating frame integrity and are accordingly aborted, creating a noticeable disruption in bus performance.